Chip 1996 April/CHIP 1996 aprilis (CD06).zip/CHIP_CD06.ISO/hypertxt.arj/9510/WINDOS.CD

Text File | 1996-03-10 | 15KB | 254 lines

          @VUtazás a 32 bit körül@N

          @VwinDOwS 90+5@N

              Gyakori vita tárgya volt a Windows 95 megjelenése elôtt,
          hogy  az  DOS-tól   független,  igazi  32   bites  operációs
          rendszer-e  vagy sem?  A témát  a korai  bétaverziók  idején
          Andrew  Schulman  elemezte alaposan  Unathorized  Windows 95
          címû könyvében. Mi arra voltunk kíváncsiak e könyv  alapján,
          hogy mi került a végsô verzióba?
              A  Windows  95 nem  más,  mint egy  DOS  és egy  Windows
          egymáson. A Windows 95  legtöbb eleme megvolt már  a Windows
          3.0-ban és a Windows for Workgroups 3.11-ben (WfW),  mostani
          megjelenésében  inkább  csak  kiforrottabbá  váltak  ezek  a
          komponensek.
              A Microsoft sokszor állította, hogy a Windows 95 immáron
          egy újraírt, integrált, a Windows 3.x-szel ellentétben DOS-t
          nem  igénylô   termék.  E   cikk  keretében   azt  szeretném
          megmutatni, hogy ez nem egészen így van -- viszont ez  semmi
          hátrányt nem jelent.


          @VMiként indul a rendszer?@N

              A  Windows  95 indulásakor  azt  hihetnénk, hogy  amikor
          nincs  AUTOEXEC.BAT  és  CONFIG.SYS,  akkor  a  DOS  nem  is
          töltôdik be. Vagyis az  a file, amit sokáig  WINBOOT.SYS-nek
          hívtak, majd IO.SYS-nek kereszteltek át, behívja a  Windowst
          és ezzel kész.
              Ez egyértelmûen nincs így  -- a Soft-ICE debuggerrel  ez
          szépen megtekinthetô:  ez ugyanis  képes úgy  bootolni, hogy
          közben  a  memóriában  marad.  Töréspontokat  aggatva  a DOS
          file-megnyitás, Extended Open/Create, Find First File,  Exec
          funkciók hívásaira érdekes dolgokat tapasztalhatunk. Az elsô
          az, hogy  ez így  -- mûködik.  Következésképp a  WINBOOT.SYS
          (így  nevezem,  mert  egyértelmûbb,  hogy  mirôl   beszélek)
          mégiscsak   DOS   hívásokat  használ.   Láthatjuk,   hogy  a
          WINBOOT.SYS végrehajtása  elôtt a  boot betöltô  megkíséreli
          megnyitni  a   DRVSPACE.BIN-t  vagy   a  DBLSPACE.BIN-t.   A
          WINBOOT.SYS  betölti  a  HIMEM.SYS-t,  az  IFSHLP.SYS-t,   a
          SETVER.EXE-t. Ezek  ismerôsek, nem?  Valójában nincs  másról
          szó, minthogy automatizálták az eddigi folyamatot. Nem  kell
          kézzel beírni az  AUTOEXEC.BAT végére, hogy  ""WIN", enélkül
          is elindul magától.


          @VHol ""lakik" az operációs rendszer?@N

              Tehát  elindult a  Windows, és  betöltôdik a  VMM32.VxD,
          amiben a Virtual Machine  Manager (VMM) is van.  Valójában a
          VMM az  operációs rendszer  -- és  ez így  van már lassan öt
          éve. Amikor  1990-ben beindult  a Windows  3.0 386  Enhanced
          módja,   már    struktúrájában   igen    hasonló   dolgokkal
          találkoztunk: a Windows  V86 üzemmódba tette  a gépet, és  a
          befutó INT 21h hívások egy részét lekezelte védett módban, a
          többit  továbbadta  a   DOS-nak.  Bizonyos  értelemben   azt
          mondhatjuk, hogy  a DOS  fut a  Windows felett,  vagy inkább
          mellett -- hiszen ugyanaz a szerepe, mint a legtöbb VxD-nek:
          kiszolgál bizonyos hívásokat. Hogy ne jussanak el a  DOS-hoz
          az INT  21h hívások,  hanem a  megfelelô VxD-k  lássák el  a
          feladatot, arról a Hook_V86_Int_Chain gondoskodik. Ezzel egy
          VxD beillesztheti  magát a  VxD-k láncolatába,  és ha késôbb
          kap egy olyan hívást, amit lekezelhet, akkor  visszatéréskor
          jelzi, hogy elintézte ezt a hívást. S mivel a DOSMGR.VxD  az
          elsô a láncban, így ez -- és rajta keresztül a DOS --  kapja
          meg utoljára a hívást,  ha egyáltalán elér odáig.  A Windows
          eddigi fejlôdésének egyik fontos eleme, hogy mely  hívásokat
          kezelnek  VxD-k,  és melyeket  nem.  A WfW  3.11  óta már  a
          file-mûveletekre is van VxD, a Windows 95-ben viszont  ilyen
          értelemben  nincs  újdonság.  (Sôt,  kompatibilitási okokból
          kicsit több hívást ad vissza a DOS-nak, mint a WfW 3.11.)
              A  Windows  386  Enhanced  módja  nem  egy  valós  módú,
          bizonytalan operációs rendszerre  épül, hanem önmagában  egy
          operációs rendszer.  Például, ha  egy DOS  ablakban egy  DOS
          hívás történik, azt nem a DOS kapja meg, hanem a VMM.  Tehát
          tulajdonképpen már évek  óta van egy  32 bites, védett  módú
          operációs rendszerünk,  csak valamiért  ezt nem  tekintettük
          lényegesnek.
              S kinek lenne  jó az, ha  a Windows 95  valóban teljesen
          újra lenne írva? A legtöbb 1.0 verziójú szoftver nem éppen a
          megbízhatóságáról híres. A Windows tényleg át lett írva,  de
          mikor?  A Windows  95 DDK-ban  szerepel például  a  VMM.INC,
          ebben az elsô  említett dátum 1988  március 5, az  alkotónak
          pedig RAL-t jelöli  meg. Ez Ralph  Lipe-ra utal, aki  most a
          Windows 95 vezetô építôje. Ha további file-okat (INT2FAPI.H,
          VPICD.INC, VNETBIOS.ASM, VKD.ASM) nézünk meg, kiderül,  hogy
          a Windowst (nagy  részét bizonyosan) tényleg  újraírták 1988
          és   1990   között   a   Windows   3.0   megjelenéséhez.  De
          hangsúlyozom: ez így is van jól.
              Ha  még   visszaemlékezünk  a   Windows  3.0-ra,   akkor
          emlékezhetünk  arra  a  sok-sok  problémára,  amit  okozott.
          Ilyesmitôl nem  kell tartanunk  a Windows  95-nél, mert  bár
          sok-sok  újdonsága  van,  a lényeges  részeit  már  évek óta
          használjuk. Ezek a részek persze nem hibátlanok, de legalább
          jól ismertek. A Windows 95 újdonságait ugyanis  nagyobbrészt
          a VxD-k szállítják, amik tulajdonképpen csak kiegészítôi  az
          operációs  rendszernek.  (E tulajdonságukat  a  Microsoft is
          beismerte a WINA20.386 VxD kapcsán.)
              Említettem, hogy valójában a VMM az operációs  rendszer.
          Sokan  azt gondolják,  hogy a  KRNL386.EXE is  az a  Windows
          3.1x-ben.  Valójában  ez  csak  egy  alkalmazás,   bármilyen
          program elindulhat, amit KRNL386.EXE-nek nevezünk -- akár  a
          COMMAND.COM is.  Ekkor lesz  egy szép,  védett módú DOS-unk.
          Vagyis  ez  egy ""sima"  DOS  extender. A  Microsoft  is így
          gondolta, kétszer is: egyszer a Microsoft C++ 7.0  bétájában
          egy módosított WIN386.EXE (ez a VMM neve a Win3.1x-ben) volt
          MSDPMI  néven.  Ezt  ugyan  nem  adták  ki,  de  hivatkozást
          találunk  rá még  a WfW  3.11-ben is  (1. kép).  Másrészt  a
          Chicago  (alias  Windows  95) egyik  korai  bétájában  ezt a
          programot DOS386.EXE-nek nevezték el.


          @VProblémák a DOS ablakban@N

              A Windows  alatti DOS-ablakok  problémája abból  adódik,
          hogy teljesítménybeli okok  miatt ezek magas  privilégiummal
          futnak.  Minden operációs  rendszernek alkut  kell kötnie  a
          robusztusság és a teljesítmény között -- egyik példa erre  a
          Windows  DOS-ablaka,  a  másik a  Windows  NT  DOS-ablaka. A
          Windows (akár 3.1x, akár 95) DOS-ablakában elindított
              @KCLI
              @KCIMKE: JMP CIMKE@N
              típusú végtelen ciklus magával rántja a rendszert, de  a
          Windows  NT-ben  nem.  Viszont  a  WinNT  DOS-ablakai   igen
          lassúak. (Mellesleg az OS/2-t is magával rántja ez a trükk.)
              Természetesen   van   más,   rendszerösszeomlást   okozó
          probléma is:  azok az  adatok, amelyek  minden task  számára
          írhatók és olvashatók. Sajnos a Windows 95-ben is sok  ilyen
          van.


          @VPSP-kövületek@N

              Térjünk  vissza  a  Win95  és  a  DOS  kapcsolatára!   A
          Microsoft Developer Network (MSDN) CD-n David Long  ""TSR-ek
          támogatása a Windows 3.1-ben"  cikke mellé jár egy  COUNTDOS
          nevû  program.  Ha  ezt  a  Windows  95  alatt  futtatjuk --
          természetesen a 32 bites lemez- és file-elérést  bekapcsolva
          --,  láthatjuk,  hogy  még mindig  szép  számmal  vannak DOS
          hívások. A DOS kezeli még mindig az idôt és a PSP-ket.
              A PSP-k? Hogyan kerülnek ezek a DOS-kövületek a  Windows
          95-be? Minden tasknak, legyen  az Win16 vagy Win32,  jut egy
          darab.  Ezt  szintén  dokumentálták  a  DDK-ban,  mégpedig a
          THCB.H file-ban.  Itt említenek  egy @KTCB_PMPSPSelector@N  nevû
          mezôt. Ha megnézzük a szelektor által kijelölt címen tanyázó
          adatokat,  akkor  döbbenten meredhetünk  az  INT 20h-ra:  ez
          bizony  tényleg  PSP-t  kezel!  Csak  egy  picit  furcsa:  a
          környezeti  változókra mutató  cím szintén  egy védett  módú
          szelektor,  a  parent PSP-re  viszont  valós módú  címzéssel
          hivatkozik. Ez megteheti, ugyanis ha megnézzük a szelektorok
          LDT bejegyzéseit, akkor láthatjuk,  hogy ezek az 1  Mbyte-os
          határ alatt helyezkednek el.
              Ezek után hogyan  lehet azt mondani,  hogy a Windows  95
          megszakítja  a  kapcsolatait   a  DOS-szal  --   ha  egyszer
          dokumentáltan  szerepel  az  egyik  fô  DOS-struktúra minden
          Windows 95 taskban?
              Érdekes módon nincs minden threadnek külön PSP-je,  csak
          minden tasknak. Sôt, a  ""minden task" kifejezés se  pontos:
          csak  a  rendszer  VM-ben futó  taskok  --  Win16, Win32  --
          váltására használja a kernel a PSP-ket. A külön VM-ben  futó
          DOS-ok  nem kapnak  PSP-t. Ebbôl  következik, és  viszonylag
          egyszerûen  ki is  deríthetô, hogy  a legtöbb  DOS hívás  az
          bizony a Set PSP funkció.


          @VKi kezeli a file-rendszert?@N

              A DOS-szal való  kapcsolattartás másik része  például az
          IFSHLP.SYS. Ha ez nincs  betöltve, akkor nem lesz  32BFA (32
          bites file-elérés).  Ez meglehetôsen  furcsa, hiszen  néhány
          VxD végzi a tényleges munkát.
              Azonban ha a WfW  3.11-bôl kiemeljük az IFSHLP.SYS-t  és
          megkíséreljük ezzel ""megetetni" a Windows 95-öt, akkor  nem
          jutunk messzire -- ez a  verzió nem ismeri például a  hosszú
          file-neveket.  Ez  azt jelzi,  hogy  az IFSHLP  valamiképpen
          mégis  aktív  részese  az  alapvetôen  védett  módban  zajló
          file-kezelésnek.
              Ha   valamilyen  módon   (ez  nem   túl  bonyolult,   de
          ismertetése nagyon  messzire vezetne)  elérjük, hogy  az INT
          21h hívások, amiket általában lekezel az IFSMGR,  eljussanak
          a  DOS-hoz,  akkor  kell  valami,  ami  megakadályozza, hogy
          eljusson a hívás  a tényleges DOS-os  file-kezelô rutinokig.
          Ez  az IFSHLP.SYS:  minden bejövô  hívást megvizsgál,  és  a
          legtöbbet visszadobja  az IFSMGR-nek.  Ezzel megtöri  az INT
          21h láncot, így nem  kerülnek végrehajtásra a lánc  legvégén
          elhelyezkedô DOS-os file-rutinok.
              Azért van  szükség erre  a mechanizmusra,  mert lehetnek
          olyan, DOS  alapú programok,  melyeknek szükségük  van arra,
          hogy lássák ezeket a  file-mûveleteket -- ilyen például  egy
          röptömörítô. Amint láttuk, ezeket a Windows 95 is megkísérli
          betölteni,  tehát  kénytelen   foglalkozni  is  velük.   (És
          lehetséges,  hogy  egy  program --  nem  túl  szabályosan --
          globális TSR-nek telepíti magát a Windows 95 alól,  ilyenkor
          is szükség lehet erre.)
              Hogy mûködött korábban ez az integrált rendszer?  Lássuk
          végül az ""új, integrált rendszer" témakörét. Ez  egyáltalán
          nem új.  Hadd idézzek  a Windows  3.1 README.WRI-jébôl:  ""A
          Microsoft  Windows  és  az MS-DOS  együtt  dolgozik,  ez egy
          integrált rendszer.  Együtt tervezték  és tesztelték  ôket a
          számítógépek széles  skáláján. A  Windows 3.1  futtatása más
          rendszereken váratlan eredményeket vagy gyenge teljesítményt
          okozhat" -- olvasható a ""Running Windows with an  Operating
          System Other Than MS-DOS" szekcióban.
              És valóban  könnyen látható,  hogy az  MS DOS  5 és  6.x
          nagyon is  tud a  Windowsról, és  együttmûködik vele.  Ennek
          legegyszerûbb   bizonyítékai    a   Smartdrive-ban    és   a
          Drivespace/Doublespace programokban  elhelyezkedô VxD-k.  Ha
          kicsit  mögé  akarunk  nézni  a  dolgoknak,  akkor   érdemes
          figyelni, amikor elindul a Windows 3.x. Ezt az INT 2Fh/1605h
          interface  segítségével   jelzi  (broadcast).   Lehet,  hogy
          meglepô,  de nemcsak  a különbözô  segédprogramok, hanem  az
          IO.SYS  és  az  MSDOS.SYS  is  elfogja  ezt  a  jelzést,  és
          intenzíven kommunikálni kezd a Windowszal. Ekkor tudatnak  a
          DOSMGR.VxD-vel olyan adatokat, mint például a gép  azonosító
          címe,  amit  az  taskváltásonként  szépen  átírogat.  (Ehhez
          kapcsolódtak a  DR-DOS 6.0  windowsos problémái,  amiket egy
          módosított DR-DOS 6.0-ban -- és persze a Novell DOS 7-ben --
          már megoldottak.)  Ugyanis az  MS DOS  5.0 és  6.x, amikor a
          Windows  386  Enhanced  módban  fut,  úgy  mûködik,   mintha
          hálózaton  lenne.  Valóban, a  DOS-ablakok  a Windows  alatt
          erôsen hasonlítanak a különálló hálózati gépekre.
              Nemcsak címeket ad át a DOS a Windowsnak, hanem  aktívan
          meg is hívja azt, mégpedig a VxD-k dokumentált ""kiskapuján"
          keresztül.  Az  INT  2Fh/1684h hívás  visszaad  egy  VxD API
          belépési pontot --  ez dokumentált is.  Az viszont már  nem,
          hogy például a DOSMGR.VxD (az elôzô hívásnál BX=15h)  milyen
          API-t nyújt. Viszont  az MS DOS-ban  szerepel ez a  bizonyos
          INT  2Fh/1684h  hívás!  A  2.  képen  a  Compaq  MS  DOS 5.0
          IBMBIO.COM-jából láthatjuk e részletet. Saját  IO.SYS-ünkben
          keressünk rá a hexa B8 84 16 CD 2F-re, hamar rábukkanunk!
              Összefoglalva   mindezeket   visszajutunk   az   eredeti
          feltevéshez:  a  Windows  95  szerkezete  és  DOS-szal  való
          kapcsolata megmaradt a régi, több tízmillió gépen  kipróbált
          megoldásnál -- és ez így nagyon is jó.

          @KNégyesi Károly@N


          @VPár szót a VxD-krôl@N

              A VxD-k a DOS .SYS-einek megfelelô 32 bites, védett módú
          Windows programok. Åltalában  32 bites eszközök  vezérlésére
          használják   ezeket    közvetlenül   vagy    a   16    bites
          eszközvezérlôkön keresztül. Valójában a VxD-k alkotják a  32
          bites operációs rendszer legfontosabb részét.
              A VxD-k a SYSTEM.INI [device] szekciójában tölthetôk be,
          a ""*" karakterrel kezdôdôek a VMM részei.

          @<9510\WINDOS1.GIF>■■@N  1. kép: Hivatkozás a VMM-re: a WfW 3.11 WIN.COM-jából ollózva...

          @<9510\windos1a.gif>■■@N  ...illetve amikor ezt ki is írja

          @<9510\WINDOS2.GIF>■■@N  2. kép: Windows-funkciót hív a DOS